jira LE-3526
cve CVE-2025-21759
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Eric Dumazet <edumazet@google.com>
commit 087c1fa

igmp6_send() can be called without RTNL or RCU being held.

Extend RCU protection so that we can safely fetch the net pointer
and avoid a potential UAF.

Note that we no longer can use sock_alloc_send_skb() because
ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.

Instead use alloc_skb() and charge the net->ipv6.igmp_sk
socket under RCU protection.

Fixes: b8ad0cb ("[NETNS][IPV6] mcast - handle several network namespace")
	Signed-off-by: Eric Dumazet <edumazet@google.com>
	Reviewed-by: David Ahern <dsahern@kernel.org>
	Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://patch.msgid.link/20250207135841.1948589-9-edumazet@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 087c1fa)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira LE-3526
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Kevin Wolf <kwolf@redhat.com>
commit 4862c88

This adds a 'bool *forward' parameter to .prepare_ioctl, which allows
device mapper targets to accept ioctls to themselves instead of the
underlying device. If the target already fully handled the ioctl, it
sets *forward to false and device mapper won't forward it to the
underlying device any more.

In order for targets to actually know what the ioctl is about and how to
handle it, pass also cmd and arg.

As long as targets restrict themselves to interpreting ioctls of type
DM_IOCTL, this is a backwards compatible change because previously, any
such ioctl would have been passed down through all device mapper layers
until it reached a device that can't understand the ioctl and would
return an error.

	Signed-off-by: Kevin Wolf <kwolf@redhat.com>
	Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
	Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
(cherry picked from commit 4862c88)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira LE-3526
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Kevin Wolf <kwolf@redhat.com>
commit 7734fb4
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-6.12.0-55.20.1.el10_0/7734fb4a.failed

Multipath cannot directly provide failover for ioctls in the kernel
because it doesn't know what each ioctl means and which result could
indicate a path error. Userspace generally knows what the ioctl it
issued means and if it might be a path error, but neither does it know
which path the ioctl took nor does it necessarily have the privileges to
fail a path using the control device.

In order to allow userspace to address this situation, implement a
DM_MPATH_PROBE_PATHS ioctl that prompts the dm-mpath driver to probe all
active paths in the current path group to see whether they still work,
and fail them if not. If this returns success, userspace can retry the
ioctl and expect that the previously hit bad path is now failed (or
working again).

The immediate motivation for this is the use of SG_IO in QEMU for SCSI
passthrough. Following a failed SG_IO ioctl, QEMU will trigger probing
to ensure that all active paths are actually alive, so that retrying
SG_IO at least has a lower chance of failing due to a path error.
However, the problem is broader than just SG_IO (it affects any ioctl),
and if applications need failover support for other ioctls, the same
probing can be used.

This is not implemented on the DM control device, but on the DM mpath
block devices, to allow all users who have access to such a block device
to make use of this interface, specifically to implement failover for
ioctls. For the same reason, it is also unprivileged. Its implementation
is effectively just a bunch of reads, which could already be issued by
userspace, just without any guarantee that all the rights paths are
selected.

The probing implemented here is done fully synchronously path by path;
probing all paths concurrently is left as an improvement for the future.

Co-developed-by: Hanna Czenczek <hreitz@redhat.com>
	Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
	Signed-off-by: Kevin Wolf <kwolf@redhat.com>
	Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
	Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
	Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
(cherry picked from commit 7734fb4)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	include/uapi/linux/dm-ioctl.h

jira LE-3526
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Benjamin Marzinski <bmarzins@redhat.com>
commit 5c977f1
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-6.12.0-55.20.1.el10_0/5c977f10.failed

Grabbing the work_mutex keeps probe_active_paths() from running at the
same time as multipath_message(). The only messages that could interfere
with probing the paths are "disable_group", "enable_group", and
"switch_group". These messages could force multipath to pick a new
pathgroup while probe_active_paths() was probing the current pathgroup.
If the multipath device has a hardware handler, and it switches active
pathgroups while there is outstanding IO to a path device, it's possible
that IO to the path will fail, even if the path would be usable if it
was in the active pathgroup. To avoid this, do not clear the current
pathgroup for the *_group messages while probe_active_paths() is
running. Instead set a flag, and probe_active_paths() will clear the
current pathgroup when it finishes probing the paths. For this to work
correctly, multipath needs to check current_pg before next_pg in
choose_pgpath(), but before this patch next_pg was only ever set when
current_pg was cleared, so this doesn't change the current behavior when
paths aren't being probed. Even with this change, it is still possible
to switch pathgroups while the probe is running, but only if all the
paths have failed, and the probe function will skip them as well in this
case.

If multiple DM_MPATH_PROBE_PATHS requests are received at once, there is
no point in repeatedly issuing test IOs. Instead, the later probes
should wait for the current probe to complete. If current pathgroup is
still the same as the one that was just checked, the other probes should
skip probing and just check the number of valid paths.  Finally, probing
the paths should quit early if the multipath device is trying to
suspend, instead of continuing to issue test IOs, delaying the suspend.

While this patch will not change the behavior of existing multipath
users which don't use the DM_MPATH_PROBE_PATHS ioctl, when that ioctl
is used, the behavior of the "disable_group", "enable_group", and
"switch_group" messages can change subtly. When these messages return,
the next IO to the multipath device will no longer be guaranteed to
choose a new pathgroup. Instead, choosing a new pathgroup could be
delayed by an in-progress DM_MPATH_PROBE_PATHS ioctl. The userspace
multipath tools make no assumptions about what will happen to IOs after
sending these messages, so this change will not effect already released
versions of them, even if the DM_MPATH_PROBE_PATHS ioctl is run
alongside them.

	Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
	Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
(cherry picked from commit 5c977f1)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	drivers/md/dm-mpath.c

jira LE-3526
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Mikulas Patocka <mpatocka@redhat.com>
commit 050a3e7
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-6.12.0-55.20.1.el10_0/050a3e71.failed

Replace spin_lock_irqsave/spin_unlock_irqrestore with
spin_lock_irq/spin_unlock_irq at places where it is known that interrupts
are enabled.

	Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
	Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
(cherry picked from commit 050a3e7)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	drivers/md/dm-mpath.c

jira LE-3526
cve CVE-2025-37799
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Daniel Borkmann <daniel@iogearbox.net>
commit 4c22276

vmxnet3 driver's XDP handling is buggy for packet sizes using ring0 (that
is, packet sizes between 128 - 3k bytes).

We noticed MTU-related connectivity issues with Cilium's service load-
balancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP
backend service where the XDP LB was doing IPIP encap led to overly large
packet sizes but only for *some* of the packets (e.g. HTTP GET request)
while others (e.g. the prior TCP 3WHS) looked completely fine on the wire.

In fact, the pcap recording on the backend node actually revealed that the
node with the XDP LB was leaking uninitialized kernel data onto the wire
for the affected packets, for example, while the packets should have been
152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes
was padded with whatever other data was in that page at the time (e.g. we
saw user/payload data from prior processed packets).

We only noticed this through an MTU issue, e.g. when the XDP LB node and
the backend node both had the same MTU (e.g. 1500) then the curl request
got dropped on the backend node's NIC given the packet was too large even
though the IPIP-encapped packet normally would never even come close to
the MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let
the curl request succeed (which also indicates that the kernel ignored the
padding, and thus the issue wasn't very user-visible).

Commit e127ce7 ("vmxnet3: Fix missing reserved tailroom") was too eager
to also switch xdp_prepare_buff() from rcd->len to rbi->len. It really needs
to stick to rcd->len which is the actual packet length from the descriptor.
The latter we also feed into vmxnet3_process_xdp_small(), by the way, and
it indicates the correct length needed to initialize the xdp->{data,data_end}
parts. For e127ce7 ("vmxnet3: Fix missing reserved tailroom") the
relevant part was adapting xdp_init_buff() to address the warning given the
xdp_data_hard_end() depends on xdp->frame_sz. With that fixed, traffic on
the wire looks good again.

Fixes: e127ce7 ("vmxnet3: Fix missing reserved tailroom")
	Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
	Tested-by: Andrew Sauber <andrew.sauber@isovalent.com>
	Cc: Anton Protopopov <aspsk@isovalent.com>
	Cc: William Tu <witu@nvidia.com>
	Cc: Martin Zaharinov <micron10@gmail.com>
	Cc: Ronak Doshi <ronak.doshi@broadcom.com>
	Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250423133600.176689-1-daniel@iogearbox.net
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 4c22276)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira LE-3526
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Toke Høiland-Jørgensen <toke@redhat.com>
commit cd3c931

Since we are about to stash some more information into the pp_magic
field, let's move the magic signature checks into a pair of helper
functions so it can be changed in one place.

	Reviewed-by: Mina Almasry <almasrymina@google.com>
	Tested-by: Yonglong Liu <liuyonglong@huawei.com>
	Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
	Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
	Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://patch.msgid.link/20250409-page-pool-track-dma-v9-1-6a9ef2e0cba8@redhat.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit cd3c931)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…pool

jira LE-3526
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Toke Høiland-Jørgensen <toke@redhat.com>
commit ee62ce7

When enabling DMA mapping in page_pool, pages are kept DMA mapped until
they are released from the pool, to avoid the overhead of re-mapping the
pages every time they are used. This causes resource leaks and/or
crashes when there are pages still outstanding while the device is torn
down, because page_pool will attempt an unmap through a non-existent DMA
device on the subsequent page return.

To fix this, implement a simple tracking of outstanding DMA-mapped pages
in page pool using an xarray. This was first suggested by Mina[0], and
turns out to be fairly straight forward: We simply store pointers to
pages directly in the xarray with xa_alloc() when they are first DMA
mapped, and remove them from the array on unmap. Then, when a page pool
is torn down, it can simply walk the xarray and unmap all pages still
present there before returning, which also allows us to get rid of the
get/put_device() calls in page_pool. Using xa_cmpxchg(), no additional
synchronisation is needed, as a page will only ever be unmapped once.

To avoid having to walk the entire xarray on unmap to find the page
reference, we stash the ID assigned by xa_alloc() into the page
structure itself, using the upper bits of the pp_magic field. This
requires a couple of defines to avoid conflicting with the
POINTER_POISON_DELTA define, but this is all evaluated at compile-time,
so does not affect run-time performance. The bitmap calculations in this
patch gives the following number of bits for different architectures:

- 23 bits on 32-bit architectures
- 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE)
- 32 bits on other 64-bit architectures

Stashing a value into the unused bits of pp_magic does have the effect
that it can make the value stored there lie outside the unmappable
range (as governed by the mmap_min_addr sysctl), for architectures that
don't define ILLEGAL_POINTER_VALUE. This means that if one of the
pointers that is aliased to the pp_magic field (such as page->lru.next)
is dereferenced while the page is owned by page_pool, that could lead to
a dereference into userspace, which is a security concern. The risk of
this is mitigated by the fact that (a) we always clear pp_magic before
releasing a page from page_pool, and (b) this would need a
use-after-free bug for struct page, which can have many other risks
since page->lru.next is used as a generic list pointer in multiple
places in the kernel. As such, with this patch we take the position that
this risk is negligible in practice. For more discussion, see[1].

Since all the tracking added in this patch is performed on DMA
map/unmap, no additional code is needed in the fast path, meaning the
performance overhead of this tracking is negligible there. A
micro-benchmark shows that the total overhead of the tracking itself is
about 400 ns (39 cycles(tsc) 395.218 ns; sum for both map and unmap[2]).
Since this cost is only paid on DMA map and unmap, it seems like an
acceptable cost to fix the late unmap issue. Further optimisation can
narrow the cases where this cost is paid (for instance by eliding the
tracking when DMA map/unmap is a no-op).

The extra memory needed to track the pages is neatly encapsulated inside
xarray, which uses the 'struct xa_node' structure to track items. This
structure is 576 bytes long, with slots for 64 items, meaning that a
full node occurs only 9 bytes of overhead per slot it tracks (in
practice, it probably won't be this efficient, but in any case it should
be an acceptable overhead).

[0] https://lore.kernel.org/all/CAHS8izPg7B5DwKfSuzz-iOop_YRbk3Sd6Y4rX7KBG9DcVJcyWg@mail.gmail.com/
[1] https://lore.kernel.org/r/20250320023202.GA25514@openwall.com
[2] https://lore.kernel.org/r/ae07144c-9295-4c9d-a400-153bb689fe9e@huawei.com

	Reported-by: Yonglong Liu <liuyonglong@huawei.com>
Closes: https://lore.kernel.org/r/8743264a-9700-4227-a556-5f931c720211@huawei.com
Fixes: ff7d6b2 ("page_pool: refurbish version of page_pool code")
	Suggested-by: Mina Almasry <almasrymina@google.com>
	Reviewed-by: Mina Almasry <almasrymina@google.com>
	Reviewed-by: Jesper Dangaard Brouer <hawk@kernel.org>
	Tested-by: Jesper Dangaard Brouer <hawk@kernel.org>
	Tested-by: Qiuling Ren <qren@redhat.com>
	Tested-by: Yuying Ma <yuma@redhat.com>
	Tested-by: Yonglong Liu <liuyonglong@huawei.com>
	Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
	Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://patch.msgid.link/20250409-page-pool-track-dma-v9-2-6a9ef2e0cba8@redhat.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit ee62ce7)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira LE-3526
cve CVE-2025-21991
Rebuild_History Non-Buildable kernel-6.12.0-55.20.1.el10_0
commit-author Florent Revest <revest@chromium.org>
commit e3e8917

Currently, load_microcode_amd() iterates over all NUMA nodes, retrieves their
CPU masks and unconditionally accesses per-CPU data for the first CPU of each
mask.

According to Documentation/admin-guide/mm/numaperf.rst:

  "Some memory may share the same node as a CPU, and others are provided as
  memory only nodes."

Therefore, some node CPU masks may be empty and wouldn't have a "first CPU".

On a machine with far memory (and therefore CPU-less NUMA nodes):
- cpumask_of_node(nid) is 0
- cpumask_first(0) is CONFIG_NR_CPUS
- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an
  index that is 1 out of bounds

This does not have any security implications since flashing microcode is
a privileged operation but I believe this has reliability implications by
potentially corrupting memory while flashing a microcode update.

When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes
a microcode update. I get the following splat:

  UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y
  index 512 is out of range for type 'unsigned long[512]'
  [...]
  Call Trace:
   dump_stack
   __ubsan_handle_out_of_bounds
   load_microcode_amd
   request_microcode_amd
   reload_store
   kernfs_fop_write_iter
   vfs_write
   ksys_write
   do_syscall_64
   entry_SYSCALL_64_after_hwframe

Change the loop to go over only NUMA nodes which have CPUs before determining
whether the first CPU on the respective node needs microcode update.

  [ bp: Massage commit message, fix typo. ]

Fixes: 7ff6edf ("x86/microcode/AMD: Fix mixed steppings support")
	Signed-off-by: Florent Revest <revest@chromium.org>
	Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
	Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250310144243.861978-1-revest@chromium.org
(cherry picked from commit e3e8917)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v6.12~1..kernel-mainline: 52012
Number of commits in rpm: 14
Number of commits matched with upstream: 10 (71.43%)
Number of commits in upstream but not in rpm: 52002
Number of commits NOT found in upstream: 4 (28.57%)

Rebuilding Kernel on Branch rocky10_0_rebuild_kernel-6.12.0-55.20.1.el10_0 for kernel-6.12.0-55.20.1.el10_0
Clean Cherry Picks: 6 (60.00%)
Empty Cherry Picks: 3 (30.00%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-6.12.0-55.20.1.el10_0/rebuild.details.txt

Includes:
* git commit header above
* Empty Commits with upstream SHA
* RPM ChangeLog Entries that could not be matched

Individual Empty Commit failures contained in the same containing directory.
The git message for empty commits will have the path for the failed commit.
File names are the first 8 characters of the upstream SHA